home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Internet
/
Collection of Internet.iso
/
infosrvr
/
dev
/
www_talk.930
/
001233_timbl@www3.cern.ch _Wed Jun 2 18:02:23 1993.msg
< prev
next >
Wrap
Internet Message Format
|
1994-01-24
|
2KB
Return-Path: <timbl@www3.cern.ch>
Received: from dxmint.cern.ch by nxoc01.cern.ch (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
id AA19897; Wed, 2 Jun 93 18:02:23 MET DST
Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
id AA08157; Wed, 2 Jun 1993 18:24:03 +0200
Received: by www3.cern.ch (NX5.67c/NX3.0S)
id AA01622; Wed, 2 Jun 93 18:16:33 +0100
Date: Wed, 2 Jun 93 18:16:33 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9306021716.AA01622@www3.cern.ch>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: weber@eitech.com (Jay Weber)
Subject: Re: HTTP ACCEPT field and MIME types
Cc: www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch
Jay,
A good point about the commas in the Accept: field. I hadn't noticed
that MIME qualified the type with parameters sometimes. It seems
there is something strange in the example you give
Content-Type: application/octet-stream;
name=foo.tar.Z; type=tar;
conversions="x-encrypt,x-compress"
that means that the MIME typing isn't coping -- in particular here
the content-encoding field isn't coping.
There are several TBC areas in the latest version (any version) which
need to be filled in before its an RFC. (An ID first maybe). And
there must of course be working implementations. The libwww uses
the Accept: field. It in fact sends one field per content-type.
It's not obvious how to distinguish between w3 parameters and MIME
parameters to a type. Maybe we don't have to.
request:
Accept: image/gif; q=0.8; width=1200; height=100; colous=256;
response:
Content-Type: image/gif; width=800; height=400; colours=10;
Tim